[SOLVED] warning: operation on 'i' may be undefined [-Wsequence-point]
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Fedora, OpenSuse, DENX Embedded Linux
Posts: 184
Original Poster
Rep:
Quote:
Originally Posted by kbp
Ah .. there's a good description of the situation here - basically the order of operations is ambiguous.
I actually came across this exact same article when researching this and it makes sense, but then I also came across this table (http://msdn.microsoft.com/en-us/libr...(v=vs.60).aspx) which indicates that Pre-increment has a higher precedence than %, so in that case it seems like order of operations shouldn't be ambiguous.
My only guess is that they actually have the same precedence, and according to this website http://www.c4learn.com/c-programming...dence-and.html they have opposite associativity which would explain why the compiler complains that order of operations is ambiguous.
My only guess is that they actually have the same precedence, and according to this website http://www.c4learn.com/c-programming...dence-and.html they have opposite associativity which would explain why the compiler complains that order of operations is ambiguous.
That's not the problem. What the compiler is complaining about is that you reference the variable ptr again (on the LHS) in the same statement where it is incremented. The ambiguity is whether the LHS will use the pre-increment or post-increment value.
Technically, the result is "undefined," which means that any result, including reformatting your disk, would be within the C language spec (though seriously in violation of the "principle of least surprise").
Sorry, had the operator precedence confused again.
I actually came across this exact same article when researching this and it makes sense, but then I also came across this table (http://msdn.microsoft.com/en-us/libr...(v=vs.60).aspx) which indicates that Pre-increment has a higher precedence than %, so in that case it seems like order of operations shouldn't be ambiguous.
This is only relevant when parsing the source code. “++i % 10” is parsed as “(++i) % 10” (and not “++(i % 10)”. The compiler can perform operations in whatever order it pleases (and in whatever way it pleases) as long as the result after the C instruction is the same provided code is valid.
Say you have: “j = ++i % 10”. Compiler might translate it to:
Code:
1. Load variable i to register α.
2. Increment value in α.
3. Save reminder of dividing α by 10 to register β.
4. Save β to j.
5. Save α to i.
The compiler might also swap 4th and 5th operation and the same end result would be produced. Now, if you have “i = ++i % 10”, compiler is free to apply the same logic meaning that you don't know what which value will end up in i (since 4th and 5th operation might be in any order).
What the compiler is complaining about is that you reference the variable ptr again (on the LHS) in the same statement where it is incremented. The ambiguity is whether the LHS will use the pre-increment or post-increment value.
ptr is never modified, this is not the issue. You probably meant ptr->count.
Last edited by mina86; 11-08-2013 at 11:07 AM.
Reason: fixing formatting
Distribution: Fedora, OpenSuse, DENX Embedded Linux
Posts: 184
Original Poster
Rep:
Thanks for the great responses.
Quote:
Originally Posted by mina86
This is only relevant when parsing the source code. “++i % 10” is parsed as “(++i) % 10” (and not “++(i % 10)”. The compiler can perform operations in whatever order it pleases (and in whatever way it pleases) as long as the result after the C instruction is the same provided code is valid.
Say you have: “j = ++i % 10”. Compiler might translate it to:
Code:
1. Load variable i to register α.
2. Increment value in α.
3. Save reminder of dividing α by 10 to register β.
4. Save β to j.
5. Save α to i.
The compiler might also swap 4th and 5th operation and the same end result would be produced. Now, if you have “i = ++i % 10”, compiler is free to apply the same logic meaning that you don't know what which value will end up in i (since 4th and 5th operation might be in any order).
I guess I had some incorrect assumptions like with the pre-increment it would perform step 5 after step 2, and definitely before step 4, and that post-increment, i.e. j = i++ % 10, would perform steps 2 and 5 last.
I think I will just use this method, which will eliminate step 5.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.